Abstract 



This document describes a new and innovative architectural design of using the internet to provide 
radio frequency coverage, using the Internet Distributed Access Network Architecture (iDANA). As 
the name suggests the proposed architecture enables the Access Network to be distributed over 
internet, thereby using the internet to provide the connectivity between the elements (also called units) 
comprising the iDANA. This connectivity between the elements (or units) can be realized as an open 
interface or using proprietary interface. For an operator, this architectural design not only provides a 
flexible network solution but also offers significant reduction on CAPEX needs. 

Description 

The current systems in place use what is called a distributed architecture, where the base unit and RP 
remote units (also called heads) are connected via a fiber optic cable or any other suitable media. The 
interfaces are based on proprietary protocols and the term "distributed" refers to the distribution of the 
RP remote heads supported by a given base unit. Essentially the architecture addresses the issue of 
remotely locating the RP heads from the base band unit of a single network element:. 

This paper provides a paradigm shift in the way the distributed architectures be designed to take 
advantage of the opportunities provided by the internet. Instead of merely looking at the distributed 
architecture as provided by a single network element, this paper provides a solution that will bring the 
"distributed" architecture to the network. 



As shown in Figure. 1, an iDANA is comprised of two separate units called the Access Network Unit 
(ANU) and the Transceiver Unit (TU). The ANU in turn is comprised of two logical functions called 
the Access Network Controller (ANC) and the Transceiver Server (TxrS), where ANC provides all of 
the call processing & control functions and the TxrS providing the server functionality to identify the 
correct TU & provide proper connectivity to the various distributed TUs via the internet. As shown in 
Figure 1, both TxrS and TU possess the necessary capability to meet the connectivity requirements to 
route any information via the internet. The necessary protocol for the iDAN Architecture is covered 
later in the document. 
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Figure 1 iDAN Architecture 



Having discussed the various elements that make up the iDANA, the following paragraph provides a 
discussion on how this innovative architectural design provides significant reduction in CAPEX and 
flexible network solution for an operator. 

As can be seen in Figure 2, the ANUs is connected to the various TUs via the internet. Whereas, a 
single ANU can support multiple technologies, a separate TU can be dedicated for each technology 
supported by the ANU. The ANC contained in the ANU provide a common platform to support the 
multiple technologies and the function of the TxrS is to route the different technologies to the right TU 
using internet as the distribution media. The TUs provides flexible installation options and can be used 
with satellite transponders to even increase RF coverage to even remotest comers of a network. In 
addition to TU supporting different technologies, depending upon the type of application, the TUs can 
come is different sizes covering different coverage foot prints, like the Macro, Micro, Pico, Nano etc. 
With this architecture, there are several network deployment options avaible for an operator. One 
example, would be to locate the ANUs at a common site (or location) and distributing the TUs across 
the coverage area specific to that particular operator. With the flexible installation option for the TUs, 
this can (at the minimum) save on the expenses to aquire cell sites (as is the case currently). In 
addition, if the ANUs are colocated with other network elements, then significant savings can also be 
realised on the Tl, El, T3 etc. 
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Figure 2 Network Deployment of iDANA 
iDAN Architecture — Protocol Overview 

Before providing a discussion into the iDANA Protocol, as can be seen from Figure 3, there are other 
supporting protocols that will be needed to accomplish the end to end network for a particular access 
technology. These are labeled' as "TDPL (Technology Dependent Protocol Layers)" and are beyond the 
scope of this discussion. Depending upon the access technology, details of TDPL can be found 
elsewhere or in relevant access technology standards. 



iDAN Architecture — Protocol Overview 




TDPL -Technology Dependent Protocol Layers 



Figure 3 iDAN Architecture - Protocol Overview 



There are two types of protocol layers that define the iDAN Architecture. The protocol layers defined 
in iDAN Architecture shall follow the OSI reference model. . The reference protocol layers between the 



TU and TxrS is called the "TU - TxrS Protocol Layers" and the other between the TxrS and ANC is 
called "TxrS - ANC Protocol Layers". Both these protocol layers cany signalling and traffic data. 

TV - TxrS Protocol Layers: This protocol layer defines the connectivity between the TU and the TxrS. 
For both TU & TxrS, the lower layers for this protocol shall meet the requirements for providing 
connectivity to appropriate internet protocol requirement. 

For TxrS, the layers above physical layer shall be designed in such a way that the TxrS is: 

> Able to assign and maintain the IP addresses of the various TUs supported by that particular 
TxrS. 

> Able to map the IP addresses of the various TUs to the technology supported by a particular TU 
such that the technology dependent information from the ANC can be forwarded to the right 
TU. 

> Able to define and provide the necessary security information to provide secure connection to 
TU via the internet. 

> Able to negotiate the necessary quality of service for the connection to TU. 

> Able to encapsulate the higher layer protocol information to the appropriate internet protocol 
layer requirements. 

For TU, the layers above physical layer shall be designed in such a way that the TU is: 

> Able to maintain the IP address provided by the TxrS. 

> Able to convert the base band information received from the ANC via TxrS to the appropriate 
RF signals pertaining to a specific air interface employed. The function will include (but not 
limited to) modulation, up-conversion, transmit amplification, filtering etc. 

> Able to convert the RF information to base-band to ANC via TxrS. The function will include 
(but not limited to) de-modulation, down-conversion, receive amplification, filtering etc. 

> Able to define and provide the necessary security information to provide secure connection to 
TxrS via the internet. 

> Able to negotiate the necessary quality of service for the connection to TxrS. 

> Able to encapsulate the higher layer protocol information to the appropriate internet protocol 
layer requirements. 

TxrS ~ ANC Protocol Layers: This protocol layer defines the connectivity between the TxrS and the 
ANC. Since both TxrS and ANC are functionally implemented in a single ANU, an appropriate 
physical layer (layer 1) can be defined based on the technology platform on which these functions are 
realized. Whereas, an ANC provides all the call processing and control functionalities for a particular 
access technology towards the TxrS, the ANC also provides the necessary protocol for connectivity 
towards "other network elements" (based on TDPL). The protocol on the TxrS is responsible for 
communicating to the ANC and forward the necessary information to the "TU - TxrS Protocol" of the 
TxrS. 



